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ABSTRACT 



A variety of methods and apparatus for managing deactiva- 
tion and deletion of objects and server processes are taught. 
According to some embodiments of the present invention, a 
thread of execution termed the reaper thread systematically 
cycles through a computer process deactivating and/or delet- 
ing objects based upon a variety of criteria. One suitable 
criterion for object deactivation is based upon the amount of 
time lapsed since a client has requested services of the 
object. According to the timeout criterion, the reaper thread 
determines the period of time since the last client requested 
services from the object, compares this to a timeout value 
which may be defined by any suitable entity, and proceeds 
with deactivation and/or deletion accordingly. Object dele- 
tion may have a separate criterion or be specifically 
requested by a client. A deletion flag may be set to indicate 
that object deletion is requested. When an object has 
deactivated, the reaper thread further determines if the 
deletion flag for this object is set, and, if so, further proceeds 
to perform an object deletion operation. In some 
embodiments, the reaper thread is further responsible to 
shutdown the server process under which the reaper thread 
is executing. As is well known to those skilled in the art of 
object oriented programming, a thread of execution is essen- 
tially a sequential flow of the point of execution through a 
computer process. One suitable criterion for server process 
shutdown would be related to the server process activity. 

2 Claims 10 Drawing Sheets 




03/02/2004, EAST Version: 1.4.1 



6,161,147 

Page 2 



OTHER PUBLICATIONS 

IBM Technical Disclsoure Bulletin, "Safe Device Power 
Management," May 1993, vol. 36 No. 05, pp. 123-124. 
IBM Technical Disclosure Bulletin, "Pop-Up Icon for 
Operation Event in Shared Applications," Jan. 1995, vol. 38, 
No. 01, pp. 1-2. 



IBM Technical Disclosure Bulletin, "Mechanism for 
Dynamic Resource Management," Jan. 1995, vol. 38, No. 
01, pp. 583-584. 

Rao, Bindu R., C++ and the OOP Paradigm , 1993, pub- 
lished by McGraw-Hill Inc., pp. 165-171. 



03/02/2004, EAST Version: 1.4.1 



U.S. Patent Dec 12,2000 Sheet 1 of 10 6,161,147 






/ 





Ll 



03/02/2004, EAST Version: 1.4.1 



U.S. Patent Dec 12, 2000 Sheet 2 of 10 



6,161,147 




Fig. 2 



03/02/2004, EAST Version: 1.4.1 



U.S. Patent Dec 12, 2000 Sheet 3 of 10 6,161,147 




03/02/2004, EAST Version: 1.4.1 



U.S. Patent 



Dec 12,2000 



Sheet 4 of 10 



6,161,147 



BEGIN REAPER 
THREAD CYCLE 



150 





.154 




03/02/2004, EAST Version: 1.4.1 



U.S. Patent Dec 12, 2000 Sheet 5 of 10 



6,161,147 




200 



152 



/ 



lock active servant 
list mutex 



202 



204 



1 = 1 


is i > number of 


servants in the 


i = i + 1 


active servant list? 



220 



unlock active 
servant mutex 







add servant(i) to 
deactivation 
pending list ! 





214 



03/02/2004, EAST Version: 1.4.1 



U.S. Patent Dec 12, 2000 



Sheet 6 of 10 



6,161,147 



222 



270 

L 




i = 1 


is i > the number of 


objects in the deactivation 


i = i + 1 


pending list? 



remove object(i) 
from deactivation 
pending list 



272 



call deletion hook (if 
provided) 




— w done ] 



274 



call BOA delete 
function to delete 
ORB object(i) 

I 



release object 
memory 

=1 



254 



256 



258 



1 






unquiesce ORB 






object(i) 




n j 




^266 





n 

r 


call object adaptor 
deactivation 
function 




f 


call deactivation 
hook (if provided) 




'■ .£> 



260 



262 



264 





268 



is the object(i) delete , , „ 79 
flag set? ^S~y 



Fig. 6 



03/02/2004, EAST Version: 1.4.1 



U.S. Patent 

268 



Dec. 12, 2000 



Sheet 7 of 10 



6,161,147 




Begin deleting object(i) 




300 



if the object(or operating environment) 
is managing persistent data and the 
flag object(i).is_deleted is set, then 
delete persistent data for ORB 
object(i) 



lock active object list 
mutex 



remove object(i) from 
active servant list 



unlock active object 
list mutex 



304 



-306 



-308 



302 



i r 



Fig. 7 



03/02/2004, EAST Version: 1.4.1 



U.S. Patent 



Dec 12, 2000 



Sheet 8 of 10 



6,161,147 




03/02/2004, EAST Version: 1.4.1 



U.S. Patent 



Dec 12,2000 



Sheet 9 of 10 



6,161,147 



398 



/object adaptor receives" 
( shutdown server process 
\. call 



.400 



for each active ORB object in the server 
process being shut down, call the object 
deactivation function (which performs steps 
identical to steps 254 - 274) 



.402 




404 



1 r 

^done^ 



Fig. 9 



03/02/2004, EAST Version: 1.4.1 



U.S. Patent 



Dec 12, 2000 



Sheet 10 of 10 



6,161,147 



398 



'object activation function 
receives activation call 
from object adaptor 



-410 



object activation function allocates memory for 
object 



.412 



add object to active 
object list (using 
mutex) 



.414 



call activation hook 



.416 



register object with 
object adaptor 



.418 



^done^ 



Fig. 10 



03/02/2004, EAST Version: 1.4.1 



6,lf 

1 

METHODS AND APPARATUS FOR 
MANAGING OBJECTS AND PROCESSES IN 
A DISTRIBUTED OBJECT OPERATING 
ENVIRONMENT 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This application is related to co-pending patent applica- 
tion Ser. No. 08/414,240, filed simultaneously herewith, 
which is assigned to the assignee of the present application 
and is incorporated herein by reference in its entirety. 

BACKGROUND OF THE INVENTION 

The present invention relates generally to the manage- 
ment of active objects in distributed object based client/ 
server computing systems. More specifically, the present 
invention teaches methods and apparatus for managing the 
activation, deactivation and deletion of objects and pro- 
cesses within a distributed object operating environment that 
utilizes a reaper to periodically check the status of the 
managed objects. 

In the computer industry, there have been increasing 
efforts in recent years to provide distributed, object oriented 
operating environments which permit computers intercon- 
nected via a computer network to work together more 
efficiently. As used herein, the term "distributed object" or 
"object" refers to an encapsulated package of code and data 
that can be manipulated by operations through an interface. 
Thus, distributed objects will be seen by those skilled in the 
art of object oriented programming (OOP) as including the 
basic properties that define traditional programming objects. 
However, distributed objects differ from traditional pro- 
gramming objects by the inclusion of two important fea- 
tures. First, distributed objects are multilingual. That is, the 
interfaces of distributed objects are defined using an inter- 
face definition language (IDL) that can be mapped to a 
variety of different programming languages. One such inter- 
face definition language is Object Management Group's 
IDL. Second, distributed objects are location-independent, 
i.e., distributed objects can be located anywhere in a net- 
work. This contrasts sharply with traditional programming 
objects which typically exist in a single address space. 

Distributed objects can be object clients or object servers, 
depending upon whether they are sending requests to other 
objects or replying to requests from clients. In a distributed 
object operating environment, requests and replies are made 
through an Object Request Broker (ORB) that is aware of 
the locations and status of the objects. One architecture 
which is suitable for implementing such an ORB is provided 
by the Common Object Request Broker Architecture 
(CORBA) specification which is incorporated herein by 
reference. The CORBA specification was developed by the 
Object Management Group (OMG) to define the distributed 
computing environment world in terms of objects in a 
distributed client-server environment, where server objects 
are capable of providing services to clients requesting the 
service. In the following discussion, the terms "object" and 
"distributed object" will be used interchangeably. 

In any multi-purpose computer system, there is a limited 
amount of transient memory resources that may be allocated 
to the resources (e.g. objects and process(es)) that are active 
within the system. Therefore, there must be some mecha- 
nism through which such resources can be deactivated 
and/or deleted thereby freeing portions of the transient 
memory for use by other resources. In most personal com- 
puter systems, this is done by the user who simply manually 
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deletes or deactivates resources that are not in use. However, 
such an approach is unsuited for distributed object based 
computing systems, since objects and processes may be 
initiated in response to calls received from remotely located 

5 clients. In larger systems, servers often run continuously as 
daemon processes that are started by the operating system 
during system initialization. As will be appreciated by those 
skilled in the art, the problem is amplified in distributed 
object based computing systems since objects and processes 

10 may be initiated in response to calls received from remotely 
located clients. Therefore, reasoned management of the 
active objects becomes a necessity. 

SUMMARY OF THE INVENTION 

15 To achieve the foregoing and other objectives and in 
accordance with the purpose of the present invention, meth- 
ods and apparatus for managing objects and processes 
within a distributed object operating environment are taught. 
According to one embodiment of the present invention a 

20 computer system capable of executing a process includes a 
central processing unit, memory that is allocated to the 
process, an active object list resident in the memory, an 
object timeout variable arranged to store a designated object 
inactivity period, an object timer variable associated with 

25 the selected object and a deactivator for deactivating the 
selected object. The computer system elements have the 
following attributes. The active object list is arranged to 
identify objects that are active in the process. The designated 
object inactivity period value is associated with a selected 

30 object and further is indicative of a period of inactivity after 
which the selected object will be deactivated when the 
object is in an active state. The object timer variable is 
arranged to store a value that is suitable for use in deter- 
mining whether the period of inactivity after which the 

35 selected object will be deactivated has been exceeded. The 
deactivator is arranged to perform the deactivation function 
when it is determined that the period of inactivity after 
which the selected object will be deactivated has been 
exceeded. 

40 

In a related embodiment, the computer system is capable 
of executing a multithreaded process and the computer 
system has a mutex associated with the active object list. The 
active object list mutex serves to synchronize access to the 

45 active object list as only the thread in possession of the 
active object list mutex may access the active object list. In 
some embodiments of the present invention, the object 
timeout variable and the object timer variable form a portion 
of the active object list. In further embodiments, each object 

50 entry in the active object list has an associated object timeout 
variable and an associated object timer variable. In another 
related embodiment, the computer system further has a 
deactivation pending list that identifies any objects that are 
ready to be deactivated. Additionally, the deactivator is 

55 arranged to only deactivate objects that are identified in the 
deactivation pending list. 

In yet another related embodiment, the computer system 
further comprises a deletion flag associated with the selected 
object. The deletion flag is arranged to indicate whether its 

60 associated object is to be deleted. 

In a separate embodiment of the invention, a computer 
system capable of executing a computer process includes a 
central processing unit, memory that is allocated to the 
process, a server timeout variable arranged to store a des- 

65 ignated inactivity period value that is associated with the 
process, the designated inactivity period value being indica- 
tive of a period of inactivity after which the process will be 
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deactivated, a server timer variable associated with the accessed within a period that exceeds their designated 

process and arranged to store a value that is suitable for use inactivity period by identifying the managed objects that are 

in determining whether the period of inactivity after which designated for deactivation on a deactivation pending list, 

the server will be deactivated has been exceeded, and a ( c ) checking the status of the deletion flags associated with 

deactivator for deactivating the server when it is determined 5 each 0 f the objects in the deactivation pending list to 

that the period of inactivity after which the server will be determine whether their associated managed objects have 

deactivated has been exceeded. been mar kcd for deletion and freeing the memory associated 

In another embodiment of the present invention, a com- suc h managed objects, and (d) deactivating the man- 

puter system capable of executing a multi-threaded process aged objects that are identified in the deactivation pending 

is disclosed. According to this embodiment, the computer 10 ^ and are not mar ked for deletion. Furthermore, the 

system comprises a central processing unit, memory that is me thod includes the step of periodically repeating steps 

allocated to the process, an active object list resident in the (a)-{d) 

memory the active object list being arranged to identify e , te of ^ , 

objects that are acuve in the process, an active object list ^ implemented method of managing 

mute* that permits only one thread to access the acuve 1S .. , n t J of ^ , 

object list at any time, an object timeout variable arranged ^ ^ are fof ^ m a process executin ^ a 

to store a designated server mactivity penod value that is , er tem lba , has ao aclive object M mat identifies 

associated wuh the object, the des.gnated object mactrnty ^ ^ > o Each ^ ^. has m MMcU|ed 

period value being . "^cative of a penod I of inactivity after maB d ^ st0[e a ^ of a 

which the object will be deactivated, an object Umer variable 20 desi ted object nod and an timer 

associated with the object and arranged to store a value that tQ valuc of a ^ >t 

is suitable for use in determining whether the penod of ^ aQ ^ tssodttci ^ which the 

inactivity after which the object w.U be deactivated has been m ^ ^ m6thod com ^ |hc 

exceeded and a deactivator for deactivating the selected ^ a ^ lemented st of (a) determming whether , be 

object when it is determined that the penod of inactivUy 25 y ^ ^ ^ ^ associated ^ a 

after which the selected object will be deacUvated has been predetennined value> wherein when 

exceeded. ^ e va | ue ^ored { Q me associated timeout variable is set to 

According to one aspect of the present mvention, a a predetermined value> me assoc iated object will not be 

computer implemented method of managing objects used in deactivated based on inactivity, (b) checking the timer 

a process executing on a computer system is taught. Each 30 variabIe associated with a selected object to determine 

managed object occupies memory allocated to the process whe ther the associated timer variable is in an uninitialized 

and has an associated designated object mactivity penod. &tatCj whcrcin whcQ the timcr variabIe is found to 

The computer implemented method comprises the computer be in ±c uninitialized sta te, thc associated timer variable is 

implemented steps of, for each managed object, periodically ^fc^^ and (c) determining whether the time that has 

checking to determine whether the managed object has not 35 ehpsed gince &e {imGT yariMc associated with a selected 

been accessed within a penod that exceeds the associated object exceeds the designated object inactivity period asso- 

designated object inactivity period and deactivating man- dated ^ ^ wherein wheQ the associated 

aged objects that are determined to have not been accessed pefiod for mactivit y is exceeded, the associated object is 

within a period that exceeds their designated mactivity designated for deactivation by identifying the selected object 

P enod - 40 on a deactivation pending list. The method further teaches 

A related method aspect includes the computer imple- ( d ) repeating the necessary ones of steps (a)-(c) for each of 

mented steps of periodically checking to determined the managed objects to determine whether any of the man- 

whether the process has not been accessed within a period aged objects should be deactivated based on inactivity and 

that exceeds a designated server inactivity period that is ( e ) deacdvatmg me managed objects mat are identified in the 

associated with the process, and deactivating the process 45 deactivation pending list. Still further, the method teaches 

when it is determined that the process has not been accessed periodically repeating steps (d) and (e) while the process is 

within a period that exceeds the designated process inactiv- active on me computer system, 
ity period. In some embodiments, each managed object has 

an associated timeout variable arranged to store a value BRIEF DESCRIPTION OF THE DRAWINGS 

indicative ^of the associated designated object inactivity 50 ^ e inycnti t mer ^ farther objectives and advan- 

period, wherein when the value stored in a selected one of A , r ? 4 . » . / c .i_ 

V . . " . . , tages thereof, may best be understood by reference to the 

the timeoutvariables is set to a predetermined value, the f< * description taken in conjunction with the accom- 

associated object will not be deactivated based on mactivity. drawings in which: 

In a separate method aspect of the present invention, a ^ . ,,.,.„,,. f 

A K . . !L * c ■ u- . a m t-f FIG. 1 is a pictorial illustration of various computers 

computer implemented method of managing objects used in 55 r , , . f , r 

r r . . * *? • u hnked together m a computer network; 

a process executing on a computer system that has an active 6 r , 

object list that identifies the managed objects is taught. FIG. 2 illustrates dia^ammatically the major components 

Herein each managed object has ao associated designated of a computer id FIG. 1; 

object inactivity period and an associated deletion flag FIG. 3 is a pictorial illustration of a computer process in 

having a state that indicates that the associated managed 60 accordance with one embodiment of the present invention, 

object has been marked for deletion. The method of the wherein the computer process has multiple threads of 

present aspect of the invention comprises the computer execution, file identifiers, memory allocation, ao object 

implemented steps of (a) for each managed object, checking resident therein, an active object list, and a deactivation 

to determine whether the managed object has not been pending list; 

accessed within a period that exceeds the associated desig- 65 FIG. 4 is a flow chart illustrating an execution cycle of a 

nated object inactivity period, (b) designating for deactiva- reaper thread of execution in accordance with one aspect of 

tion managed objects that are determined to have not been the present invention; 
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FIG. 5 is a flow chart illustrating in more detail one to the client, is handled by the ORB. It should be pointed out 

embodiment of step 152 of FIG. 4, specifically, FIG. 5 shows that the client and server can exist within the same process, 

a couple of paths of execution for the reaper thread to take on the same host computer, or on two different host com- 

when reaping objects based upon a time out criterion; puters. 

FIG. 6 is a flow chart illustrating in more detail one 5 An "object interface" is a specification of the operations, 

embodiment of step 222 of FIG. 5, specifically, FIG. 6 shows attributes, and exceptions that an object provides, 

a couple of paths of execution for the reaper thread to take Preferably, object interfaces for distributed objects are wnt- 

when deactivating objects present in the deactivation pend- ten using an IDL. As noted above, objects perform services 

ing list- through their interfaces. The use of interfaces therefore 

FIG.' 7 is a flow chart illustrating in more detail one ™ relieves the need of clients to be aware of the programming 

embodiment of the object memory reclamation step 268 of languages used to define the methods and data of the objects 

P IG in the service. 

FIG.' 8 is a flow chart illustrating in more detail one ,L J 1 * Reaper Thread 

embodiment of step 154 of FIG. 4, specifically, FIG. 8 shows According to some embodiments of the presen invenUon 

a couple of paths of execution for the reaper thread to take 15 * th ™ d lof execution termed the reaper t^ead systematically 

when reaping a server based upon a time out criterion; > *™f a ? m P utcr deacUvatmg^d/ordele - 

™„ « . * • .„ . . c u- . ing objects based upon a variety of criteria. One suitable 

9 15 * * ow chart mustratm 8 a mcXhod A f0f ^ jeCt criterion for object deactivation is based upon the amount of 

adapter to shutdown a server process m accordance withone ^ smce a dient has fequested Mrvices of the 

aspect of the present mvention; and . . 20 object. According to the timeout criterion, the reaper thread 
FIG. 10 is a flow chart illustrating a method for acuvaung determines me pe riod of time sirjce me last client requested 
an object in accordance with one aspect of the present ^ces from the object, compares this to a timeout value 
invention. which may be defined by any suitable entity, and proceeds 
DETAILED DESCRIPTION OF THE with deactivation and/or deletion accordingly. Object dele- 
INVENTION 25 tion may have a separate criterion or be specifically 
I. Definition of Terms requested by a client. A deletion flag may be set to indicate 
As used herein, the term "distributed object" or "object" that object deletion is requested. When an object has 
refers to an encapsulated package of code and data that can deactivated, the reaper thread further determines if the 
be manipulated by operations through a defined interface deletion flag for this object is set, and, if so, further proceeds 
that is associated with an object. Thus, distributed objects 30 to perform an object deletion operation. In some 
will be seen by those skilled in the art as including the basic embodiments, the reaper thread is further responsible to 
properties that define traditional programming objects. shutdown the server process under which the reaper thread 
However, distributed objects differ from traditional pro- is executing. As is well known to those skilled in the art of 
gramming objects by the inclusion of two important fea- object oriented programming, a thread of execution is essen- 
tures. First, distributed objects are multilingual. The inter- 35 tially a sequential flow of the point of execution through a 
faces of distributed objects are defined using an interface computer process. One suitable criterion for server process 
definition language that can be mapped to a variety of shutdown would be related to the server process activity, 
different programming languages. One such interface defi- As will be appreciated by those skilled in the art, objects 
nition language is OMG's IDL. Second, distributed objects are instances of an object class activated in a server process, 
are location-independent, i.e., distributed objects can be 40 In particular, distributed objects are contemplated. Typically, 
located anywhere in a network. This contrasts sharply with distributed objects are implemented (by the ORB and/or the 
traditional programming objects which typically exist in the host computer) under computer processes. Computer pro- 
same address space as the client. Distributed objects can be cesses provide a well known and common framework under 
object clients or object servers, depending upon whether which computer systems implement different threads of 
they are sending requests to other objects or replying to 45 execution. By way of analogy, a computer process can be 
requests from other objects. Requests and replies are made thought of as a domain partitioned within a computer 
through an Object Request Broker (ORB) that is aware of system. 

the locations and status of the objects. In actuality, a process typically includes address space 

A "distributed object system" or "distributed object oper- (i.e. a portion of memory allocated to only the process), a set 

ating environment" refers to a system comprising distributed 50 of file descriptors, a process identification number, and one 

objects that communicate through an ORB. or more threads of execution (often referred to as threads). 

An "object reference" or "objref ' is a value that contains Multi-threaded systems, such as contemplated by the present 

a pointer or some other type of indirection to an object The invention, allow for multiple threads to run concurrently in 

creation and definition of object references will be familiar a single process. For a more detailed description of threads, 

to those skilled in the art. 55 multi-threaded processes, and principles of concurrency, 

A "client" as defined herein refers to an entity that sends please see "Concurrency Within DOE Object Implementa- 

a request to second object In this model, the second object tions" by Dr. Robert Hagmann, Version 0.91, May 27, 1993, 

is referred to as a "server object" or a "target object". Thus, published by SunSoft and incorporated herein by reference 

clients invoke operations, or implementations, from servers. in its entirety. 

In a distributed object environment, clients need not have 60 Asa direct result of the framework of computer processes, 

knowledge of the implementation programming language, all entities residing under a single process will share the 

nor does the implementation have to have knowledge of the process' limited resources (i.e. memory and files). Thus 

client's programming language due to the requirement of multiple distributed objects residing in a single process will 

multilingual character of such objects. Clients and servers in have efficient communications via local transport, 

distributed object environments need only communicate in 65 Furthermore, data can be loaded into memory that all objects 

terms of the interface definition language. As noted above, residing in the single process will have direct access to. 

the request by the client to the server, and the server's reply However, programmers may have other motivations 
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(beyond efficient transport and data sharing) which negate 
the advantages gained by having many objects in a single 
process. For instance, different objects will have different 
objectives and may rely on different assumptions about the 
process. These motivations generate a need for orderly, 
multi-process distributed object operating environments as 
disclosed by the present invention. In allowing programmers 
to keep objects within separate processes, the ORB may 
prevent conflict between and maintain the integrity of 
objects within processes. As a case in point, an object in a 
first server process may go into an error condition and begin 
chaotically writing within its server process memory. 
Nevertheless, objects running in separate server processes 
will remain intact since these processes have their own 
memory, files, and flow control. Thus, in certain embodi- 
ments of the present invention, each server process will 
include its own reaper thread. However, the methods and 
apparatus of the present invention are also well suited for use 
in a single process operating environment. 

In a preferred embodiment of the present invention, 
distributed objects and computer processes are resident on 
one or more computers linked together by a network. The 
network may take any suitable form. By way of example, a 
representative network arrangement 10 is illustrated in FIG. 
1. The network arrangement 10 includes a first computer 12 
which is coupled to a transmission line 14. The network 10 
further includes a server, router or the like 16 in addition to 
other computers 18, 20, and 22 such that data and instruc- 
tions can be passed among the networked computers. The . 
design, construction and implementation of computer net- 
works will be familiar to those of skill in the art. 

A representative computer 30 suitable for use as comput- 
ers 12, 18, 20, and/or 22 of FIG. 1 is illustrated schemati- 
cally in FIG. 2. Computer 30 includes a central processing 
unit (CPU) 32 which is coupled bidirectionally with random 
access memory (RAM) 34 and unidirectionally with read 
only memory (ROM) 36. Typically, RAM 34 is used as a 
"scratch pad" memory and includes programming instruc- 
tions and data, including distributed objects and their asso- 
ciated code and state, for processes currently operating on 
CPU 32. ROM 36 typically includes basic operating 
instructions, data and objects used by the computer to 
perform its functions. In addition, a mass storage device 38, 
such as a hard disk, CD ROM, magneto-optical (floptical) 
drive, tape drive or the like, is coupled bidirectionally with 
CPU 32. Mass storage device 38 generally includes addi- 
tional programming instructions, data and objects that typi- 
cally are not in active use by the CPU, although the address 
space may be accessed by the CPU, e.g., for virtual memory 
or the like. Each of the above described computers option- 
ally includes an input/output source 40 that typically 
includes input media such as a keyboard, pointer devices 
(e.g., a mouse or stylus) and/or network connections. Addi- 
tional mass storage devices (not shown) may also be con- 
nected to CPU 32 through a network connection. It will be 
appreciated by those skilled in the art that the above 
described hardware and software elements, as well as the 
networking devices, are of standard design and construction, 
and will be well familiar to those skilled in the art. 

FIG. 3 illustrates a multi-threaded process 100 in accor- 
dance with one embodiment of the present invention. The 
process 100 may be implemented on a computer such as 
computer 30 and includes multiple threads such as thread 
102, allocated memory 104 which may include both persis- 
tent and transient memory, file identifiers 106, at least one 
object such as object 108, and active object list 120, and a 
deactivation pending list 122. When the server process 100 
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is activated, the server memory 104 is allocated, the server 
process 100 is registered with the Object Request Broker, 
and any other activation functions are performed. For a more 
detailed description of server process activation, as well as 

5 other methods and apparatus related to server process man- 
agement in a distributed object operating environment, 
please see Menges et. al's copending U.S. patent application 
Ser. No. 08/408,245 entitled "METHODS AND APPARA- 
TUS FOR MANAGING COMPUTER PROCESSES" 

to which is incorporated herein by reference in its entirety. 
The object 108 includes state 110 and code 112. The 
object 108 is typically defined by the state 110 and the code 
112. Code 112 is essentially the operating instructions by 
which the object executes. State HO is thus the remaining 

15 portion which is not executable code. When an object is 
activated (or created), the memory for the instance variables 
(i.e. the state) is allocated and any necessary activation 
functions are performed. At this point the object 108 is ready 
to accept client requests for services. For a more detailed 

20 description of object activation, as well as other methods and 
apparatus related to object management, please see 
Brownell et. al.'s copending U.S. patent application Ser. No. 
08/408,954 entitled "METHODS, APPARATUS, AND 
DATA STRUCTURES FOR MANAGING OBJECTS" 

25 which is incorporated herein by reference. 

In one embodiment of the present invention, the active 
object list 120 is a list having a pointer for each active object. 
The deactivation pending list 122 is a list having a pointer 
for each active object which is "marked" for deactivation. 

30 The active object list 120 and the deactivation pending list 
122 may be used by the reaper thread during its cycle in the 
following manner. The reaper thread will work its way 
through the active object list 120 evaluating each of the 
objects present. When an object present in the active object 

35 list 120 is determined to need "reaping", the reaper thread 
will add the object to the deactivation pending list 122. After 
evaluating each of the objects present in the active object list 
120, the reaper thread will then go through the deactivation 
pending list 122, initiating deactivation when appropriate, 

40 and also removing from the deactivation pending list 122 
any objects which have completed deactivation. 

Referring next to FIGS. 4-9, a process suitable for 
managing the deactivation and deletion of objects and server 
processes in accordance with one embodiment of the present 

45 invention will be described. In this embodiment, a reaper 
thread is used to periodically check the status of the objects 
that are active within a particular process as well as the 
process itself. For each object that is active within a process, 
the reaper determines whether the object has been accessed 

50 within a predetermined designated period that is associated 
with the object. If an object has not been accessed within the 
designated period, the object is marked for deactivation. At 
an appropriate time (which may be after all or a number of 
the objects in a process have been checked) the reaper thread 

55 proceeds to deactivate the objects marked for deactivation. 
The reaper thread can also check the status of the process 
itself, to provide a mechanism for shutting down processes 
that are not currently being used. In the embodiment 
described, the reaper takes the form of a dedicated thread of 

60 execution and acts solely on the objects within a single 
process. Accordingly, each server process may be provided 
with its own reaper thread. In alternative embodiments, a 
single reaper could be designed that reaps a number of 
processes and/or the reaper thread of execution could be 

65 arranged to perform other tasks as well. 

Referring next to FIG. 4, the activity cycle of a dedicated 
reaper thread that reaps a single process will be described. 
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The reaper thread's activity begins at step 150. Initially, the 
thread is used to reap the objects that are active within the 
process in step 152. In effect, the reaper thread will check 
each of the objects to determine whether it has been utilized 
within a designated amount of time. In the described 5 
embodiment, each object has an associated designated 
access period that indicates the amount of time the object 
must be inactive before it is automatically deactivated by the 
reaper. If a particular object hasn't been accessed within its 
designated access period, it will be marked for deactivation, 10 
as will be described in more detail below with reference to 
FIG. 5. After all of the objects have been reaped in step 152, 
the reaper thread moves to step 154 where it reaps the 
process. In effect, the reaping of the process checks to 
determine whether the process has been accessed within an 15 
associated designated server access time period and if not, 
the server is shutdown. After the server process has been 
reaped in step 154, there are two possible outcomes as 
illustrated by step 156. If in step 154 the server process was 
shutdown then it will no longer be executing and the reaping 20 
is completed. On the other hand, when the server process has 
not been shutdown, the reaping cycle will be repeated after 
a suitable delay as illustrated by step 158. The reaper thread 
will then continue to cycle through the objects and process 
as long as the server process is active. 25 

Referring next to FIG. 5, the object reaping step 152 of 
FIG. 4 will be described in more detail. Initially, in step 202, 
the reaper thread will acquire an active object list mutex. The 
active object list mutex prevents other threads from access- 
ing the active object list simultaneously with the reaper 30 
thread which helps prevent concurrency problems. This is 
because only the thread owning the active object list mutex 
may access the active object list. It should be appreciated 
that if the active object list mutex is locked when it is 
initially accessed by the reaper thread, the reaper thread will 35 
merely wait in a sleep state until the mutex is released, at 
which point the reaper thread will wake possessing the 
active object list mutex. In any event, after the active object 
list mutex has been locked by the reaper thread, the reaper 
thread will proceed to reap all of the objects listed in the 40 
active object list. 

In the flow chart shown, the reaping of the objects is 
illustrated by way of the loop created by steps 204-214. 
Thus, step 204 merely illustrates the constraints of the loop 
which essentially require that the reaper thread reap each of 45 
the objects in the active object list. Initially, in a step 206, the 
reaper thread determines whether a object time out variable 
(object timeout (i)) that is associated with the first object 
(object(i)) is set to zero. In the notation of the flow chart, the 
counter "i" is set to unity for the first object and thus the first so 
checked object timeout is object timeout (1). When the 
object time out variable is set to zero (or another suitable 
predetermined number) the associated object will not be 
deactivated regardless of how long it has been since it was 
accessed. Accordingly, if the value of the object time out 55 
variable is set to zero for the first object, the logic control 
returns to step 204 where the counter (i) is incremented and 
the reaping process is repeated for the next object listed in 
the active object list. 

When the object time out variable (object timeout (i)) for 60 
object (i) is not set to zero, the reaper proceeds to step 208 
where it is determined whether a timer variable (object tick 
(i)) associated with the same object (i.e. object (i)) is set to 
zero. The object timer variable is typically set to zero by two 
separate occurrences. Initially, when an object is activated, 65 
the object timer variable is set to zero. Additionally, each 
time that the object is accessed, the object timer variable is 



reset to zero. Thus, a zero value in the object timer variable 
indicates that this is the first pass of the reaper since the 
object was either activated or invoked. Accordingly, when it 
is determined in step 208 that this is the first pass of the 
reaper since an access or an activation, the reaper proceeds 
to step 216 where the timer variable associated with the 
object (i.e. object tick (i)) is set or reset to indicate the 
current time. After the timer variable has been set to the 
current time in step 216, the logic returns to step 204 for 
processing of the next entry in the active object list. 

When it is determined in step 208 that the timer variable 
associated with the current object is not set to zero, the 
reaper proceeds to step 210 where it is determined whether 
the o bject has be^n inac tive for a period o ftime which 
exceeds its permissible Hmit. This is accomplished by sub- 
tracting the value stored as object tick (i) from the current 
time and determining whether the difference is greater than 
the designated access period as indicated by the value in the 
object time out (i) variable. If the object's time out limit has 
not been exceeded, then the logic again returns to step 204 
where analysis of the next object in the active object list 
begins. 

If it is determined in step 210 that the designated access 
period associated with the object has been exceeded, the 
reaper proceeds to step 212 where it determines whether a 
deactivation pending list is full. If the deactivation pending 
list is already full then it is impossible to add any additional 
objects to the list during this pass and the logic will again 
return to step 204 so that it can look at the next entry in the 
active object list. It should be appreciated that in the 
described embodiment, the reaper thread will continue its 
analysis of all active objects. However, since the deactiva- 
tion pending list is known to be full, in alternative 
embodiments, it may be desirable to skip steps 210-214 
during the processing of additional objects since even if they 
have timed out they cannot be added to the deactivation 
pending list. Typically, the deactivation pending list will be 
large enough so that overflows are very unlikely. The actual 
size of the deactivation pending list may vary widely in 
accordance with the needs of any particular system. In other 
embodiments, it may be appropriate to design the deactiva- 
tion pending list to be able to vary in size, thereby avoiding 
a situation wherein the deactivation pending list is full. 

When it is determined in step 212 that the deactivation 
pending list is not full, then the reaper thread proceeds to 
step 214 where the object which has been inactive for an 
extended period is added to the deactivation pending list. 
After the object (i) has been added to the deactivation 
pending list, the reaper returns to step 204 where it begins 
its analysis of the next entry in the active object list. After 
all of the entries in the active object list have been processed, 
the reaper thread will proceed to step 220 where the active 
object list mutex is unlocked. This permits other threads to 
access the active object list as required. After the active 
object list mutex has been unlocked and released, the reaper 
proceeds to step 222 where it deactivates the objects listed 
in the deactivation pending list (deleting the deactivated 
objects when appropriate) as will be described in more detail 
below with reference to FIG. 6. After the appropriate objects 
have been deactivated, the reaper proceeds to step 154 of 
FIG. 4 where it reaps the server process as will be described 
in more detail below with reference to FIG. 8. 

Referring next to FIG. 6, the deactivation objects step 222 
of FIG. 5 will be described in more detail. In the flow chart 
of FIG. 6, the reaper deactivation cycle is illustrated by way 
of the loop created with steps 252-270. Step 252 merely 
illustrates the constraints of the loop which essentially 
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require that the reaper thread process each of the objects available to clients and further cannot be activated. Subse- 
present in the deactivation pending list. Initially, in a step quent to step 274, the reaper thread proceeds to execute the 
254, the reaper quiesces an object (object (i)) in the deac- steps of reclaiming object memory for object(i), and remov- 
tivation pending list that is associated with the first object ing the object (i) from the deactivation pending list 270. 
(object(i)). In the notation of the flow chart, the counter "i" 5 These steps are performed identical to the description in the 
is set to unity for the first object in the deactivation pending preceding paragraph; therefore no further discussion is pro- 
list and thus the first object quiesced is object (1). When vided. 

quiesced, the object will no longer receive requests from Referring next to FIG. 7, one embodiment of the reclaim 

remote clients. object (i) memory step 268 will be described in more detail. 

After performing a quiesce call in step 254, in a step 256 10 In an initial step 300, the reaper thread begins the reclama- 

it is determined if the quiesce call failed. If the call failed, Uon method. In an optional step 302, when it is determined 

this typically indicates that the object has already been that (1) the object has persistent data and (2) the object 

deactivated. Thus if the call failed, the deactivation method delete flag (i) is set, then the persistent data associated with 

222 proceeds in a step 270 where the reaper thread removes the object is deleted. One suitable method for transparently 

object (i) from the deactivation pending list and then control 15 incorporating persistent data into an object is described in 

is returned to step 252 where the counter "i" is incremented Hapner et. al.'s copending U.S. patent application Ser. No. 

by unity and either the object deactivation loop is completed 08/414,770 entitled "METHODS AND APPARATUS FOR 

or the next object in the deactivation pending list is pro- PROVIDING TRANSPARENT PERSISTENCE INADIS- 

cessed. TRIBUTED OBJECT OPERATING ENVIRONMENT' 

If the quiesce call succeeds, control proceeds to a step 258 20 which is incorporated herein by reference in its entirety. One 
where it is determined if a object delete flag (i) is set. The suitable method for managing persistent data for a plurality 
object delete flag (i) is set to indicate that the object (i) is to of objects is described in Hapner et. al/s copending U.S. 
be deleted (as opposed to just deactivated). Additionally, the patent application Ser. No. 08/414,119 entitled "METHODS 
object delete flag (i) will prevent new clients from using the AND APPARATUS FOR MANAGING A DATABASE IN 
object if it is set. Typically the object delete flag (i) is 25 A DISTRIBUTED OBJECT OPERATING ENVIRON- 
initialized when the object is activated in the process. When MENT" which is incorporated herein by reference in its 
the object delete flag (i) is not set, control proceeds to a step entirety. Note that if the object implements its own mecha- 
260 where the Object Adapter deactivation function is called nism for maintaining persistent data, then the process of 
which alters an object adapter state to indicate that a deleting persistent data may be best performed in the dele- 
subsequent request to the object requires the object to be 30 tion hook execution step 272 of FIG. 6. 
activated. Next, in an optional step 262, a deactivation hook In a next step 304, the reaper thread lozks the active object 
is called. The deactivation hook may be provided by any list mutex. As discussed previously, when the active object 
suitable entity such as the object developer and may be list mutex is locked, the active object list can only be 
provided by a couple of different entities. In step 262 any accessed by the thread in possession of the corresponding 
steps which the object developer requires the object to 35 mutex, which in this case is the reaper thread. Once the 
perform at deactivation should be performed. By way of mutex is acquired the reaper thread deletes the object (i) 
example, if the object implements its own persistent storage from the active object list in a step 306 and subsequently, in 
mechanism, the deactivation hook is an appropriate location a step 308, unlocks the active object list mutex. 
to place operations which would perform storage and Referring next to FIG. 8, the server process reaping step 
cleanup of the object's persistent data. After executing the 40 154 of FIG. 4 will be described in more detail. Initially, -in 
deactivation hook in step 262, in a step 264 the reaper thread a step 352 a determination is made as to whether a server 
checks again to determine if the object delete flag (i) is set. time out variable is set to zero. If so, the server is not to be 
Step 264 is included as the deactivation hook may have set shut down based on inactivity and no reaping is done of the 
the flag. server process. Accordingly, the server reaping step is com- 

If in step 264 it is determined that the object delete flag (i) 45 pleted and the reaper thread will proceed to steps 156 and 

is not set, then control proceeds to a step 266 where the 158 of FIG. 4 where it will delay before repeating the reaper 

object is unquiesced. Then, in a step 268, the reaper thread thread cycle. 

releases the server process memory which has been alio- If the determination in step 352 is that a server time out 
cated to the object (i), thereby making the resources avail- variable is not set to zero, the reaper thread will proceed to 
able to other entities. One embodiment of step 268 will be 50 step 354 where it determines whether the server timer 
described in more detail below with reference to FIG. 7. variable is equal to zero. The server timer variable is 
After the object (i) memory has been released within the typically set to zero by two separate occurrences. Initially, 
server process, object (i) is removed from the deactivation when a server process is activated, the server timer variable 
pending list in a step 270 and process control is passed back is set to zero. Additionally, each time that the server process 
to step 252 wherein the counter "i" is incremented and, 55 is accessed (as for example would happen on the occurrence 
depending upon the value of "i", the deactivation cycle of any request to any object that resides in the process), the 
proceeds either to process the next object in the deactivation server timer variable is reset to zero. Thus, a zero value in 
pending list or to step 154 of FIG. 4. the server timer variable indicates that this is the first pass of 
Traveling across the YES branches of decision steps 258 the reaper since the process was either started or accessed, 
or 264 (i.e. the object delete flag (i) is set) the flow of 60 Accordingly, the server timer variable is set to the current 
execution proceeds with a step 272 where a deletion hook is time and the reaping of the server process is complete. It 
executed. The deletion hook is optionally provided by any should be appreciated that when the server timer variable is 
suitable entity such as the object developer and typically set to zero, the current pass of the reaper thread is the first 
performs tasks which the object developer desires to have pass since the server was activated or accessed and accord- 
performed prior to object deletion. Then, in a step 274, the 65 ingly step 360 is merely initiating or reinitiating the timer, 
reaper thread calls the Object Adapter delete function to When the determination in step 354 is that the server timer 
delete the object (i). After step 274, the object (i) is no longer variable is not equal to zero, the reaper thread passes to step 
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356 where it determines whether the amount of time that is 
elapsed since the server was last accessed exceeds the 
amount of time allotted in the server time out variable. That 
is, does the value of the current time minus the value of the 
server timer variable exceed the value of the server time out 5 
variable. If not, the server reaping step is completed. 

When it is determined in step 356 that the server has not 
been accessed in the allotted amount of time, the server 
process will be deactivated. To facilitate deactivation, the 
reaper thread will make a call to the object adapter in step to 
358 requesting that the object adapter initiate the shutdown 
server process. Accordingly, the mechanics of the shut down 
server process will not be described in detail herein. 
However, one thing that needs to be done before the server 
shutdown is that all of the active objects must be deacti- 15 
vated. 

It should be appreciated that at the time the server process 
is to be shut down, there may be active objects that have 
been registered with the object request broker (ORB). 
Accordingly, it is desirable to inform the object request 20 
broker of their impending deactivation. Of course, the actual 
deactivation procedure can be handled in any suitable man- 
ner and will vary to a great extent in accordance with the 
nature of the particular system. In the described 
embodiment, this ORB level object deactivation is handled 25 
by an object deactivation function that is available to the 
object adapter. Thus, referring next to FIG. 9, one method 
398 by which the object adapter (OA) may respond to a 
shutdown server request will be briefly described. The 
method 398 begins when the OA receives a shutdown server 30 
process call in step 400. By way of explanation, this method 
would be suitable to perform in response to the call for 
server shutdown step 358 of FIG. 8. After receiving the 
shutdown call, the object deactivation function is called for 
each and every object listed in the active object list. Steps 35 
identical to steps 254-274 of FIG. 6 have been found to 
work well as an object deactivation function. In some 
embodiments, identical code could called upon in both step 
402 and steps 254-275 of FIG. 6. Then, after all the objects 
in the server process have been deactivated, the server could 40 
be shutdown in a step 404. Server shutdown essentially 
releases the system resources which the server process has 
been utilizing, making the resources available to other 
computer entities. 

Referring next to FIG. 10, one suitable method for acti- 45 
vating an object in accordance with one embodiment of the 
present invention will be described in detail now. In a first 
step 410, an object activation function receives an activation 
call from the Object Adapter (OA). For example, a client 
may invoke an object to request a service but the object may 50 
not be active. In response to this invocation, the OA must 
activate the object. Initially, the object activation function 
will allocate memory for the object in the process. As will 
be appreciated by those skilled in the art of object oriented 
programming, typically an entity called a constructor is 55 
executed to create an instance of the object class. Once the 
memory is allocated, in a step 414 the OA adds the object to 
the active object list. Similar to previously described active 
object list interactions, the OA will lock and unlock the 
mutex appropriately. Next, in a step 416, the OA will call the 60 
object activation hook. The activation hook is defined to 
implement any steps required by the object at activation. The 
activation hook may be provided by suitable entities such as 
the object developer. Typical steps include initializing data 
and executing any persistent data storage mechanisms. Once 65 
the activation hook has been executed, the object is regis- 
tered with the OA and is thus ready to accept client requests. 



Although only one embodiment of the present invention 
has been described, it should be understood that the present 
invention may be embodied in many other specific forms 
without departing from the spirit or scope of the invention. 
Particularly, the mutex mechanism described for use in 
synchronizing access to the active object list may be imple- 
mented through other well known techniques. For example, 
read/write locks are another suitable form of synchroniza- 
tion variables which may be used to control access to the 
active object list. 

In addition, the reader will understand that the sequencing 
of steps in many of the disclosed methods could be rear- 
ranged and still accomplish the intended goals of the present 
invention. For instance, the specification has described that 
within the reaping object method of FIG. 5 the reaper thread 
first processes the active object list and then processes the 
deactivation pending list. However, switching the order so 
that first the deactivation pending list is processed and then 
the active object list is processed will accomplish the 
intended result. 

Furthermore, although the invention has been described in 
the context of object deactivations that result from delay 
periods based on time delays, it should be appreciated that 
the delay periods could alternatively be based on other 
discernible factors such as the number of times an object or 
a server has been accessed. For example, an active object 
may maintain a counter indicating the number of times the 
object has been used during a predefined period of lapsed 
time. If the number fell below some predetermined 
threshold, then the object would be reaped. 

Therefore, the present examples are to be considered as 
illustrative and not restrictive, and the invention is not to be 
limited to the details given herein, but may be modified 
within the scope of the appended claims. 

What is claimed is: 

1. A computer system capable of executing a multi- 
threaded process, the computer system comprising: 

a central processing unit; 

memory that is allocated to the process; 

an active object list resident in the memory, the active 
object list being arranged to identify all objects that are 
active in the process, such objects residing in the 
memory that is allocated to the process, wherein each 
active object is identified by a corresponding object 
entry in the active object list, wherein each object entry 
includes, 

an object timeout variable arranged to store an object 
inactivity period value that is based upon the require- 
ments of the particular active object identified by the 
object entry, wherein the object inactivity period 
indicates a period of inactivity after which the par- 
ticular active object is deactivated, 
an associated object timer variable arranged to store a 
value that is suitable for use in determining whether 
the period of inactivity after which the particular 
active object is deactivated has been exceeded, and 
an associated deletion flag that is arranged to indicate 
whether its associated active object is to be deleted; 
wherein each of the object inactivity period values 
included in the active object list are designated based 
upon the particular amount of time each of the associ- 
ated active objects must be inactive in order to be 
automatically deactivated, and wherein the object inac- 
tivity period values included in the active object list can 
be different from ooe another, 
an active object list mutex that permits only one thread to 
access the active object list at any time; 
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process timeout variable arranged to store a designated 
process inactivity period value that is associated with 
the process, the designated process inactivity period 
value being indicative of a period of process inactivity 
after which the process is deactivated; 5 
process timer variable associated with the process and 
arranged to store a value that is suitable for use in 
determining whether the period of process inactivity 
after which the process is deactivated has been 
exceeded; and 

reaper for deactivating the selected active object when 
it is determined that the period of inactivity after which 
the selected object is deactivated has been exceeded, 
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and when it has been determined that all active objects 
in the active object list that are identified by a corre- 
sponding deletion flag have been deactivated by the 
reaper, then reaping the process if it has been deter- 
mined that the period of process inactivity after which 
the process will be deactivated has been exceeded. 
2. A computer system as recited in claim 1 further 
comprising a deactivation pending list that identifies any 
objects that are ready to be deactivated and wherein the 
deactivator is arranged to only deactivate objects that are 
identified in the deactivation pending list. 
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